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Enhanced Mail System Status Codes 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2003). All Rights Reserved. 
Abstract 


This document defines a set of extended status codes for use within 
the mail system for delivery status reports, tracking, and improved 
diagnostics. In combination with other information provided in the 
Delivery Status Notification (DSN) delivery report, these codes 
facilitate media and language independent rendering of message 
delivery status. 
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1. Overview 


There is a need for a standard mechanism for the reporting of mail 
system errors richer than the limited set offered by SMTP and the 
system specific text descriptions sent in mail messages. There is a 
pressing need for a rich machine-readable, human language independent 
status code for use in delivery status notifications [DSN]. This 
document proposes a new set of status codes for this purpose. 


SMTP [SMTP] error codes have historically been used for reporting 
mail system errors. Because of limitations in the SMTP code design, 
these are not suitable for use in delivery status notifications. 
SMTP provides about 12 useful codes for delivery reports. The 
majority of the codes are protocol specific response codes such as 
the 354 response to the SMTP data command. Each of the 12 useful 


codes are overloaded to indicate several error conditions. SMTP 
suffers some scars from history, most notably the unfortunate damage 
to the reply code extension mechanism by uncontrolled use. This 


proposal facilitates future extensibility by requiring the client to 
interpret unknown error codes according to the theory of codes while 
requiring servers to register new response codes. 


The SMTP theory of reply codes are partitioned in the number space in 
such a manner that the remaining available codes will not provide the 
space needed. The most critical example is the existence of only 5 
remaining codes for mail system errors. The mail system 
classification includes both host and mailbox error conditions. The 
remaining third digit space would be completely consumed as needed to 
indicate MIME and media conversion errors and security system errors. 


A revision to the SMTP theory of reply codes to better distribute the 
error conditions in the number space will necessarily be incompatible 
with SMTP. Further, consumption of the remaining reply-code number 
space for delivery notification reporting will reduce the available 
codes for new ESMTP extensions. 


The following status code set is based on the SMIP theory of reply 
codes. It adopts the success, permanent error, and transient error 
semantics of the first value, with a further description and 
classification in the second. This proposal re-distributes the 
classifications to better distribute the error conditions, such as 
separating mailbox from host errors. 


Document Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14 [RFC2119]. 
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2. Status Code Structure 


This document defines a new set of status codes to report mail system 
conditions. These status codes are used for media and language 
independent status reporting. They are not intended for system 
specific diagnostics. 


The syntax of the new status codes is defined as: 

status-code = class "." subject "." detail 

class = OMAMA NANEN 

subject = 1*3digit 

detail = 1*3digit 
White-space characters and comments are NOT allowed within a status- 
code. Each numeric sub-code within the status-code MUST be expressed 
without leading zero digits. 
Status codes consist of three numerical fields separated by ".". The 
first sub-code indicates whether the delivery attempt was successful. 
The second sub-code indicates the probable source of any delivery 


anomalies, and the third sub-code indicates a precise error 
condition. 


Example: 2.1.23 


The code space defined is intended to be extensible only by standards 
track documents. Mail system specific status codes should be mapped 
as close as possible to the standard status codes. Servers should 
send only defined, registered status codes. System specific errors 
and diagnostics should be carried by means other than status codes. 


New subject and detail codes will be added over time. Because the 
number space is large, it is not intended that published status codes 
will ever be redefined or eliminated. Clients should preserve the 
extensibility of the code space by reporting the general error 
described in the subject sub-code when the specific detail is 
unrecognized. 
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The class sub-code provides a broad classification of the status. 
The enumerated values for each class are defined as: 


2.XXX.XXX Success 


Success specifies that the DSN is reporting a positive delivery 
action. Detail sub-codes may provide notification of 
transformations required for delivery. 


4.XXX.XXX Persistent Transient Failure 


A persistent transient failure is one in which the message as 
sent is valid, but persistence of some temporary condition has 
caused abandonment or delay of attempts to send the message. 
If this code accompanies a delivery failure report, sending in 
the future may be successful. 


5.XXX.XXX Permanent Failure 


A permanent failure is one which is not likely to be resolved 
by resending the message in the current form. Some change to 


the message or the destination must be made for successful 
delivery. 


A client must recognize and report class sub-code even where 
subsequent subject sub-codes are unrecognized. 


The subject sub-code classifies the status. This value applies to 
each of the three classifications. The subject sub-code, if 
recognized, must be reported even if the additional detail provided 


by the detail sub-code is not recognized. The enumerated values for 
the subject sub-code are: 


X.0.XXX Other or Undefined Status 
There is no additional subject information available. 


X.1.XXX Addressing Status 


The address status reports on the originator or destination 
address. It may include address syntax or validity. These 
errors can generally be corrected by the sender and retried. 


X.2.XXX Mailbox Status 


Mailbox status indicates that something having to do with the 
mailbox has caused this DSN. Mailbox issues are assumed to be 
under the general control of the recipient. 
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X.3.XXX Mail System Status 


Mail system status indicates that something having to do with 
the destination system has caused this DSN. System issues are 
assumed to be under the general control of the destination 
system administrator. 


X.4.XXX Network and Routing Status 


The networking or routing codes report status about the 
delivery system itself. These system components include any 
necessary infrastructure such as directory and routing 
services. Network issues are assumed to be under the control 
of the destination or intermediate system administrator. 


X.5.XXX Mail Delivery Protocol Status 


The mail delivery protocol status codes report failures 
involving the message delivery protocol. These failures 
include the full range of problems resulting from 
implementation errors or an unreliable connection. 


X.6.XXX Message Content or Media Status 


The message content or media status codes report failures 
involving the content of the message. These codes report 
failures due to translation, transcoding, or otherwise 
unsupported message media. Message content or media issues are 
under the control of both the sender and the receiver, both of 
which must support a common set of supported content-types. 


X.7.XXX Security or Policy Status 


The security or policy status codes report failures involving 
policies such as per-recipient or per-host filtering and 
cryptographic operations. Security and policy status issues 
are assumed to be under the control of either or both the 
sender and recipient. Both the sender and recipient must 
permit the exchange of messages and arrange the exchange of 
necessary keys and certificates for cryptographic operations. 


3. Enumerated Status Codes 
The following section defines and describes the detail sub-code. The 


detail value provides more information about the status and is 
defined relative to the subject of the status. 


Vaudreuil Standards Track [Page 5] 


RFC 3463 Enhanced Mail System Status Codes January 2003 


3.1 Other or Undefined Status 
X.0.0 Other undefined Status 
Other undefined status is the only undefined error code. It 
should be used for all errors for which only the class of the 
error is known. 
3.2 Address Status 


X.1.0 Other address status 


Something about the address specified in the message caused 


this DSN. 
Xi LL Bad destination mailbox address 
The mailbox specified in the address does not exist. For 


Internet mail names, this means the address portion to the left 
of the "@" sign is invalid. This code is only useful for 
permanent failures. 


X.1.2 Bad destination system address 


The destination system specified in the address does not exist 
or is incapable of accepting mail. For Internet mail names, 
this means the address portion to the right of the "@" is 
invalid for mail. This code is only useful for permanent 
failures. 


Xeles Bad destination mailbox address syntax 
The destination address was syntactically invalid. This can 
apply to any field in the address. This code is only useful 
for permanent failures. 

X.1.4 Destination mailbox address ambiguous 
The mailbox address as specified matches one or more recipients 
on the destination system. This may result if a heuristic 
address mapping algorithm is used to map the specified address 
to a local mailbox name. 


X.1.5 Destination address valid 


This mailbox address as specified was valid. This status code 
should be used for positive delivery reports. 
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X.1.6 Destination mailbox has moved, No forwarding address 


The mailbox address provided was at one time valid, but mail is 
no longer being accepted for that address. This code is only 
useful for permanent failures. 


XL, Bad sender’s mailbox address syntax 


The sender’s address was syntactically invalid. This can apply 
to any field in the address. 


x.1.8 Bad sender's system address 


The sender’s system specified in the address does not exist or 
is incapable of accepting return mail. For domain names, this 
means the address portion to the right of the "@" is invalid 
for mail. 


3.3 Mailbox Status 
X.2.0 Other or undefined mailbox status 


The mailbox exists, but something about the destination mailbox 
has caused the sending of this DSN. 


X21 Mailbox disabled, not accepting messages 


The mailbox exists, but is not accepting messages. This may be 
a permanent error if the mailbox will never be re-enabled or a 
transient error if the mailbox is only temporarily disabled. 


KBs? Mailbox full 


The mailbox is full because the user has exceeded a per-mailbox 
administrative quota or physical capacity. The general 
semantics implies that the recipient can delete messages to 
make more space available. This code should be used as a 
persistent transient failure. 


LS Message length exceeds administrative limit 
A per-mailbox administrative message length limit has been 
exceeded. This status code should be used when the per-mailbox 


message length limit is less than the general system limit. 
This code should be used as a permanent failure. 
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X.2.4 Mailing list expansion problem 


The mailbox is a mailing list address and the mailing list was 
unable to be expanded. This code may represent a permanent 
failure or a persistent transient failure. 


3.4 Mail system status 

X.3.0 Other or undefined mail system status 
The destination system exists and normally accepts mail, but 
something about the system has caused the generation of this 
DSN. 

Xe Se l Mail system full 
Mail system storage has been exceeded. The general semantics 
imply that the individual recipient may not be able to delete 
material to make room for additional messages. This is useful 
only as a persistent transient error. 

X32 2 System not accepting network messages 
The host on which the mailbox is resident is not accepting 
messages. Examples of such conditions include an immanent 
shutdown, excessive load, or system maintenance. This is 
useful for both permanent and persistent transient errors. 

X33 System not capable of selected features 
Selected features specified for the message are not supported 
by the destination system. This can occur in gateways when 
features from one domain cannot be mapped onto the supported 
feature in another. 

X.3.4 Message too big for system 
The message is larger than per-message size limit. This limit 
may either be for physical or administrative reasons. This is 
useful only as a permanent error. 


X.3.5 System incorrectly configured 


The system is not configured in a manner that will permit it to 
accept this message. 
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3.5 Network and Routing Status 
X.4.0 Other or undefined network or routing status 
Something went wrong with the networking, but it is not clear 
what the problem is, or the problem cannot be well expressed 
with any of the other provided detail codes. 
XA No answer from host 
The outbound connection attempt was not answered, because 


either the remote system was busy, or was unable to take a 
call. This is useful only as a persistent transient error. 


X.4.2 Bad connection 


The outbound connection was established, but was unable to 
complete the message transaction, either because of time-out, 
or inadequate connection quality. This is useful only as a 
persistent transient error. 


Ke Aces Directory server failure 


The network system was unable to forward the message, because a 
directory server was unavailable. This is useful only as a 
persistent transient error. 


The inability to connect to an Internet DNS server is one 
example of the directory server failure error. 


X.4.4 Unable to route 


The mail system was unable to determine the next hop for the 
message because the necessary routing information was 
unavailable from the directory server. This is useful for both 
permanent and persistent transient errors. 


A DNS lookup returning only an SOA (Start of Administration) 
record for a domain name is one example of the unable to route 
error. 

X.4.5 Mail system congestion 
The mail system was unable to deliver the message because the 


mail system was congested. This is useful only as a persistent 
transient error. 


Vaudreuil Standards Track [Page 9] 


RFC 3463 Enhanced Mail System Status Codes January 2003 


X.4.6 Routing loop detected 


A routing loop caused the message to be forwarded too many 
times, either because of incorrect routing tables or a user- 
forwarding loop. This is useful only as a persistent transient 
error. 


X.4.7 Delivery time expired 
The message was considered too old by the rejecting system, 


either because it remained on that host too long or because the 
time-to-live value specified by the sender of the message was 


exceeded. If possible, the code for the actual problem found 
when delivery was attempted should be returned rather than this 
code. 


3.6 Mail Delivery Protocol Status 

X.5.0 Other or undefined protocol status 
Something was wrong with the protocol necessary to deliver the 
message to the next hop and the problem cannot be well 
expressed with any of the other provided detail codes. 

XO Invalid command 
A mail transaction protocol command was issued which was either 
out of sequence or unsupported. This is useful only as a 
permanent error. 


M92 Syntax error 


A mail transaction protocol command was issued which could not 
be interpreted, either because the syntax was wrong or the 


command is unrecognized. This is useful only as a permanent 
error. 
X53 Too many recipients 


More recipients were specified for the message than could have 
been delivered by the protocol. This error should normally 
result in the segmentation of the message into two, the 
remainder of the recipients to be delivered on a subsequent 
delivery attempt. It is included in this list in the event 
that such segmentation is not possible. 
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X.5.4 Invalid command arguments 


A valid mail transaction protocol command was issued with 
invalid arguments, either because the arguments were out of 
range or represented unrecognized features. This is useful 
only as a permanent error. 


XD Wrong protocol version 


A protocol version mis-match existed which could not be 
automatically resolved by the communicating parties. 


3.7 Message Content or Message Media Status 


X.6.0 Other or undefined media error 


Something about the content of a message caused it to be 
considered undeliverable and the problem cannot be well 
expressed with any of the other provided detail codes. 


X.6.1 Media not supported 
The media of the message is not supported by either the 
delivery protocol or the next system in the forwarding path. 
This is useful only as a permanent error. 

X.6.2 Conversion required and prohibited 
The content of the message must be converted before it can be 
delivered and such conversion is not permitted. Such 
prohibitions may be the expression of the sender in the message 


itself or the policy of the sending host. 


X.6.3 Conversion required but not supported 


The message content must be converted in order to be forwarded 
but such conversion is not possible or is not practical by a 
host in the forwarding path. This condition may result when an 
ESMTP gateway supports 8bit transport but is not able to 
downgrade the message to 7 bit as required for the next hop. 


X.6.4 Conversion with loss performed 


This is a warning sent to the sender when message delivery was 
successfully but when the delivery required a conversion in 
which some data was lost. This may also be a permanent error 
if the sender has indicated that conversion with loss is 
prohibited for the message. 
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X.6.5 Conversion Failed 


A conversion was required but was unsuccessful. This may be 
useful as a permanent or persistent temporary notification. 


3.8 Security or Policy Status 


X.7.0 Other or undefined security status 


Something related to security caused the message to be 
returned, and the problem cannot be well expressed with any of 
the other provided detail codes. This status code may also be 
used when the condition cannot be further described because of 
security policies in force. 


Xd sl Delivery not authorized, message refused 


The sender is not authorized to send to the destination. This 
Can be the result of per-host or per-recipient filtering. This 
memo does not discuss the merits of any such filtering, but 
provides a mechanism to report such. This is useful only as a 
permanent error. 


Xa T2 Mailing list expansion prohibited 


The sender is not authorized to send a message to the intended 
mailing list. This is useful only as a permanent error. 


>, Care aac Security conversion required but not possible 
A conversion from one secure messaging protocol to another was 
required for delivery and such conversion was not possible. 
This is useful only as a permanent error. 

XT Security features not supported 
A message contained security features such as secure 
authentication that could not be supported on the delivery 
protocol. This is useful only as a permanent error. 

XD Cryptographic failure 
A transport system otherwise authorized to validate or decrypt 
a message in transport was unable to do so because necessary 


information such as key was not available or such information 
was invalid. 
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Cryptographic algorithm not supported 


A transport system otherwise authorized to validate or decrypt 
a message was unable to do so because the necessary algorithm 
was not supported. 


> ae Be 


Message integrity failure 


A transport system otherwise authorized to validate a message 
was unable to do so because the message was corrupted or 
altered. This may be useful as a permanent, transient 
persistent, or successful delivery code. 
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5. Security Considerations 


This document describes a status code system with increased 


precision. 


Use of these status codes may disclose additional 


information about how an internal mail system is implemented beyond 
that currently available. 


Vaudreuil 
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Appendix A - Collected Status Codes 


Other address status 

Bad destination mailbox address 

Bad destination system address 

Bad destination mailbox address syntax 
Destination mailbox address ambiguous 
Destination mailbox address valid 
Mailbox has moved 

Bad sender’s mailbox address syntax 
Bad sender’s system address 


xx KK KKK S 
hh PR AO 
DMIYKDUBWNHEO 


Other or undefined mailbox status 

Mailbox disabled, not accepting messages 
Mailbox full 

Message length exceeds administrative limit. 
Mailing list expansion problem 


xx MM XK 
NNMNN NY 
BWNE O 


Other or undefined mail system status 
Mail system full 

System not accepting network messages 
System not capable of selected features 
Message too big for system 


xx MM XM 
WWW WW WwW 
BWNE O 


X.4.0 Other or undefined network or routing status 
X.4.1 No answer from host 

X.4.2 Bad connection 

ES Routing server failure 

X.4.4 Unable to route 

X.4.5 Network congestion 

X.4.6 Routing loop detected 

X.4.7 Delivery time expired 

X.5.0 Other or undefined protocol status 
Kid L Invalid command 

X.5.2 Syntax error 

X.5.3 Too many recipients 

X.5.4 Invalid command arguments 

SS Wrong protocol version 

X.6.0 Other or undefined media error 

oil Media not supported 

X.6.2 Conversion required and prohibited 
X.6.3 Conversion required but not supported 
X.6.4 Conversion with loss performed 

X.6.5 Conversion failed 
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Other or undefined security status 

Delivery not authorized, message refused 
Mailing list expansion prohibited 

Security conversion required but not possible 
Security features not supported 

Cryptographic failure 

Cryptographic algorithm not supported 
Message integrity failure 


MMM MM XM XM OS 
YAA A 
YHUBWNEO 


Appendix B - Changes from RFC1893 
Changed Authors contact information. 
Updated required standards boilerplate. 


Edited the text to make it spell-checker and grammar checker 
compliant. 


Modified the text describing the persistent transient failure to more 
closely reflect current practice and understanding. 


Eliminated the restriction on the X.4.7 codes limiting them to 
persistent transient errors. 
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Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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